In the current wireless networking world, client complaints are usually the trigger for setting up packet capture at a wireless access point. In such a case, a customer has already suffered to the point of finding it necessary or worth the effort to report a problem to the service provider.
The service provider may respond to the complaint by setting up special packet capture and debug modules which control an access point to capture all packets and subject them to one or more debug procedures in an attempt to identify a problem at the specific access point associated with the customer complaint. Such an approach may result in the detection of recurring problems but may not definitively explain the source of the original complaint. This is because such post complaint packet capture collects packets communicated after the initial problem and not packets corresponding to the time of the initial problem or immediately preceding the reported problem, which, if available, might have been useful in determining the cause of the customer's complaint so that corrective measures could be taken.
Thus, while configuring packet capture in response to a complaint from a specific user may be useful, the fact that the customer had to complain about a service problem before action can be taken can lead to a disgruntled customer. Furthermore configuring an access point to capture and report all packets for debugging can involve the capture and communication of a large amount of data even though much of the traffic may have nothing to do with the reported problem.
While it may be possible to detect the source of some problems by capturing and studying packets at a single access point, some problems may involve excessive handoffs between access points and/or different interfaces. From the perspective of one interface there may seem to be no communications problem and a user may be able to communicate successfully for a brief period of time. However because of repeated handoffs or for other reasons, which do not appear as communications failures to an individual access point, a communications session may be dropped or subjected to undesirable interruptions which are unsatisfactory to a user of a particular wireless terminal. While a particular device may encounter problems because of individual device settings, other devices may not encounter such problems, and such problems may not appear as communications failures or problems to the access points servicing the wireless terminal encountering the communications problem. This can be particularly the case with devices which support multiple communications modes of operation and handoffs may occur from an interface using one communications technology to an interface which uses another communications technology.
In view of the above discussion it should be appreciated that there is a need for methods and apparatus which would allow for detection of communications problems before the reporting of complaints by individual customers and the collection of information which would allow the source of the failures to be determined rather than simply the source of future failures. There is also a need for methods and apparatus that would allow for the detection and/or diagnosing of problems which may interfere with the quality of service provided to a customer, but which may not appear to be a communications failure from the perspective of an individual communications interface or access point.